[% setvar title One Should Not Get Away With Ignoring System Call Errors %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>One Should Not Get Away With Ignoring System Call Errors</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Jarkko Hietaniemi &lt;<a href='mailto:jhi@iki.fi'>jhi@iki.fi</a>&gt;
  Date: 22 Aug 2000
  Mailing List: <a href='mailto:perl6-language@perl.org'>perl6-language@perl.org</a>
  Number: 140
  Version: 1
  Status: Developing</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<a name='EXECUTIVE SUMMARY'></a><h1>EXECUTIVE SUMMARY</h1>
<p>If something fails, you should care.</p>
<a name='TERMINOLOGY'></a><h1>TERMINOLOGY</h1>
<p>In the following 'system calls' mean anything not in the core language
calling an external service, be it a 'real' system call (such as
accept(), fork(), mkdir()) or a 'library' call (such as print(),
syswrite() getpwent()).</p>
<p>The difference is often arbitrary and depends on the implementation
details of the operating system and the libraries.  This difference is
irrelevant for the purposes of this RFC (though relevant for the
low-level implementation of this proposal).</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>The 'strict' pragma (or whatever form it takes in perl6) should
include in its 'default set of strictness' a new subpragma, 'system'.
This subpragma has the following semantics:</p>
<ul>
<li><a name='For many system calls it is possible to say during compile time that ignoring their return value is foolish and should be punished (by aborting during compilation). Examples of such system calls: open(), mkdir(), chdir(). There simply isn't an excuse for ignoring their return values.'></a>For many system calls it is possible to say during <b>compile time</b>
that ignoring their return value is foolish and should be punished
(by aborting during compilation).  Examples of such system calls:
open(), mkdir(), chdir().  There simply isn't an excuse for ignoring
their return values.</li>
<li><a name='For other system calls aborting during compile time may be too harsh: print() is an obvious example. But print() can fail, too: out of disk space, out of quota, closed socket. Such softer failures are indicated (at C level) by e.g. return of -1 and/or turning on errno. Such failures are detectable during runtime, and if, running under 'use strict', should croak. Lexical warnings could warn about such system calls: &quot;print() can fail during runtime&quot;.'></a>For other system calls aborting during compile time may be too harsh:
print() is an obvious example.  But print() can fail, too: out of disk
space, out of quota, closed socket.  Such softer failures are
indicated (at C level) by e.g. return of -1 and/or turning on errno.
Such failures are detectable during <b>runtime</b>, and if, running under
'use strict', should croak.  Lexical warnings could warn about such
system calls: &quot;print() can fail during runtime&quot;.</li>
</ul>
<a name='Cheating Is Still Possible'></a><h2>Cheating Is Still Possible</h2>
<p>Not ignoring the return value is of course no guarantee of doing
anything useful with the return value:</p>
<pre>	$so_what++ unless defined fork();</pre>
<p>But detecting whether 'something useful' is done is squarely in
the realm of heavy AI.</p>
<a name='Is That An Object In Your Pocket Or Are You Just Oriented To See Me?'></a><h2>Is That An Object In Your Pocket Or Are You Just Oriented To See Me?</h2>
<p>This proposal does not deal with any object oriented issues, whether
the detected errors 'throw' any 'exceptions' and how the user can
'catch' them.  The proposed strict handling of system call failures
should be independent of any higher level concepts such as object
oriented 'exception handling'.  Exception handling is welcome to
provide ways to muster these low-level error conditions, though.</p>
<a name='MIGRATION ISSUES'></a><h1>MIGRATION ISSUES</h1>
<p>By having this new level of bondage-and-discpiline tucked away under
'use strict' the quick hack one liner nature of Perl is still available.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>perl6-language-errors</p>
<p>perl6-language-strict</p>
<p>perl6-language-io</p>
</div>
